Federated Credential Management API

1. Introduction

This section is non-normative.

As the web has evolved there have been ongoing privacy-oriented changes (e.g Safari, Firefox, Chrome) and changes to the underlying privacy principles (e.g. Privacy Model).

With this evolution, fundamental assumptions of the web platform are being redefined or removed. Access to cookies in a third-party context are one of those assumptions. While overall good for the web, the third-party cookie deprecation removes a fundamental building block used by certain designs of federated identity.

The Federated Credential Management API aims to bridge the gap for the federated identity designs which relied on third-party cookies. The API provides the primitives needed to support federated identity when/where it depends on third-party cookies, from sign-in to sign-out and revocation.

In order to provide the federated identity primitives without the use of third-party cookies the API places the User Agent as a mediator between RPs and IDPs. This mediation requires user consent before permitting the RPs and IDPs to know about their connection to the user.

The specification leans heavily on changes in the User Agent and IDP and minimally on the RP. The FedCM API provides a way to authenticate, fetch tokens, revoke the provided tokens, and allow for front-channel logout.

1.1. Use Cases

The below use case scenarios illustrate some basic supported flows. Each supported flow below occurs inside an iframe or in an XHR request. Additional scenarios, including sample code, are given in the Identity Use Cases in Browser Catalog.

1.1.1. Sign-up

A Sign-up occurs when the user is registering a new account at the Relying Party using their Identity Provider.

For instance, a user navigates to a Relying Party in their browser and creates an account. The Relying Party displays supported Identity Providers to the user who selects their favorite. The user is prompted "Do you want to create an account with the Relying Party?". Upon user agreement an account is created with the Relying Party and the user has a session initialized.

1.1.2. Sign-in

After a user navigates to a Relying Party in a browser and decides to create an account by going through their § 1.1.1 Sign-up flow, there are two ways a user logs into their account once their session expires:

1.1.2.1. Auto Sign-in

Auto Sign-in occurs when the Identity Provider has already gathered permissions from the user to share their identity with the Relying Party and automatically signs the user in.

For example, the user has previously executed the § 1.1.1 Sign-up flow and then changes from their phone to their laptop. On the new device the user goes to the Relying Party and selects to sign-in using their Identity Provider. The Identity Provider knows, and proves, the user has signed up to the Relying Party and the Relying Party creates a new session for the users account.

1.1.2.2. Explicit Sign-in

An explicit sign-in occurs when the Identity Provider believes it is necessary to gather an explicit permission from the user to sign into a Relying Party, typically after the user goes through a § 1.1.3 Sign-out flow.

For example, after the user has done the § 1.1.3 Sign-out flow of the Relying Party they decide to log in again. The user visits the Relying Party and selects their Identity Provider to sign-in. The Identity Provider knows:

• the user already has an account with the Relying Party.

• the user has logged out of the Relying Party.

The user is then prompted, "Do you want to sign-in with the Relying Party?" and upon user agreement the Relying Party creates a new session with the users existing account.

1.1.3. Sign-out

After a user navigates to a Relying Party in a browser and decides to create an account by going through their § 1.1.1 Sign-up flow, there are two ways a user can clear their sessions:

1.1.3.1. RP Sign-out

The user can log out through the Relying Party by using a provided sign-out button or link provided by the Relying Party. This then removes the users session and, when the user visits the Relying Party again they will need to go through the § 1.1.2.2 Explicit Sign-in flow in order to establish a new session.

1.1.3.2. IDP Sign-out

The user can log out through the Identity Provider by using a provided sign-out system provided by the Identity Provider. After using the sign-out system the Identity Provider will log the user out of all Relying Parties the user has signed into along with logging the user out of the Identity Provider itself. Upon returning to any associated Relying Party, or the Identity Provider, the user will have to go through the § 1.1.2.2 Explicit Sign-in flow.

1.1.4. Revocation

After a user has created an account with a Relying Party there are two ways a user can cancel their account with the Relying Party:

1.1.4.1. RP Revocation

The user can delete their account through the Relying Party by using the provided cancel account system. The Relying Party informs the Identity Provider that the user has deleted (revoked) their account. When the user returns to the Relying Party they will need to complete the § 1.1.1 Sign-up flow in order to access the site.

1.1.4.2. IDP Revocation

The user can delete their account with a Relying Party by revoking Relying Party access through the Identity Provider. This can be done by going to the Identity Provider and using their revoke access system. Once access is revoked, when the user returns to the Relying Party they will need to complete the § 1.1.1 Sign-up flow in order to access the site.

1.1.5. Access

The Identity Provider while authenticating the user may also authorize access to users resources such as calendars, contacts, etc. The granting of access can be done at either sign-up or post sign-up by requesting permission from the user.

For example, a user executes the § 1.1.1 Sign-up flow with a Relying Party. During the flow the Relying Party has informed the Identity Provider they need calendar access for the user. The user will be presented with a prompt, "Do you want to give access to your Calendar to the Relying Party?". The user consents to providing access and when the flow is complete the Relying Party shows the user their calendar entries provided by the Identity Provider.

2. Examples

This specification extends the FederatedCredential type and internal algorithms to allow the exchange of identity between IDPs and RPs. When it succeeds, it returns to the RP a signed id token which the RP can use to authenticate the user.

<html>
  <head>
    <title>Welcome to my WebSite!</title>
  </head>
  <body>
    <button onclick="login('https://foo.example', '123')">Sign-in with Foo</button>
    <button onclick="logout()">logout</button>

    Welcome <span id="name"></span>!!

    <button onclick="revoke">delete account</button>

    <script>

    var user;

    const identityProvider = {
      url: provider,
      // the pre-registered client id
      clientId: clientId,
      nonce: "456"
    };

    async function login(provider, clientId) {
      const {idToken} = await navigator.credentials.get({
        // controls whether auto sign-in is enabled or not
        mediation: "optional",
        // controls abortions of the account chooser
        signal: signal

        // controls which identity providers to use
        federated: {
          // controls whether the account chooser is modal or not
          providers: [identityProvider],
        }
      });

      // ... do stuff ...
      // ... send to server ...
      // ... validate ...
      // ... update local storage ...

      user = parse(idToken);
      document.getElementById("name").innerText = user.name;
    }

    async function logout() {
      await navigator.credentials.preventSilentAccess();
    }

    async function revoke() {
      await FederatedCredential.revoke(user.id, identityProvider);
    }
    </script>
  </body>

</html>

3. Terminology

HTML Standard defines an origin as the tuple of a scheme, hostname, and port that provides the main security boundary on the web.

account

TODO(goto): find existing definition.

authentication

Process used by an Identity Provider to achieve sufficient confidence in the binding between the user and a presented identity.

Note that in some discussions and documentation, the term _authentication_ is used to refer to the federated sign-in process. However, the user does not authenticate to the RP during federated sign-in. The user authenticates to the IDP, which then provides a claim to the RP asserting the user’s identity. The user does not prove their identity to the RP.

See also:

• OIDC Connect Core § Terminology

• OIDC Connect Core § Authentication

• SAML glossary

directed identifier

A user identifier that that is unique for each site the user visits. A goal of anti-tracking policy is to promote user identifiers to become directed identifiers. See the § 9.1 Privacy Threat Model for more information.

first party

The first-party for a user action is the party that controls the origin of the top-level browsing context under which the action happened. Intuitively, this is the owner of the domain in the browser’s URL bar.

This differs from Mozilla’s definition in that Mozilla defines other parties as first parties if the user can easily discover which party it is and intends to interact with that party, for example to allow sign-in widgets to be first-party.

global identifier

A string that identifies a particular user independent of which site they’re visiting (e.g. email addresses and phone numbers). Users generally have relatively few global identifiers and can usually list and recognize them. A goal of anti-tracking policy is to prevent user identifiers from becoming global identifiers.

high-level API

A use case specific API, as opposed to a low-level API. See also high level vs low level.

id token

TODO(goto): find existing definition.

Identity Provider

IDP

A service that has information about the user and can grant that information to Relying Parties.

See also:

• OIDC Connect Core § Terminology

joining

TODO(goto): find existing definition.

logged in

TODO(goto): find existing definition.

logged out

TODO(goto): find existing definition.

low-level API

A general purpose API, as opposed to a high-level API. See also high level vs low level

out-of-band

Outside of the user agent’s context.

party

Defined by Tracking Preference Expression (DNT) as "a natural person, a legal entity, or a set of legal entities that share common owner(s), common controller(s), and a group identity that is easily discoverable by a user."

registered

TODO(goto): find existing definition.

Relying Party

RP

Website

A service that requests user information from an Identity Provider for federated sign-in or for other purposes.

See also:

• OIDC Connect Core § Terminology

• SAML glossary

session

TODO(goto): find existing definition.

Federated sign-in

Process used by a Relying Party to obtain a user identifier from an Identity Provider to which the user performed authentication.

See also:

• OIDC Connect Core

site

A set of origins that are all same site with each other. Note that there are problems (Public Suffix List Problems) with using registrable domains as a logical boundary.

third party

A third-party for a user action is any party that isn’t the first party or the user (the second party).

unregistered

TODO(goto): find existing definition.

unsanctioned tracking

Unsanctioned Web Tracking

user

A human or program that controls a user agent.

user identifier

A pair of a site and a (potentially-large) integer allocated by that site that is used to identify a user on that site. A single user will generally have many user IDs that refer to them, and a single site may or may not know that multiple user identifiers refer to the same user.

4. High Level Design

At a high level, the Identity Federation Management API works by the intermediation of cooperating IDPs and RPs.

The § 5 The Identity Provider API and the § 6 The Relying Party API defines a set of HTTP APIs that cooperating IDPs and IDPs exposes as well as the entry points in the § 7 The Browser API that they can use.

The user agent intermediates in such a matter that makes it impractical for the API to be used for tracking purposes, while preserving the functionality of identity federation.

This document defines the APIs in the following order:

1. The § 5 The Identity Provider API

2. The § 6 The Relying Party API

3. The § 7 The Browser API

5. The Identity Provider API

The IDP proactively and cooperatively exposes itself as a comformant agent by exposing a series of HTTP endpoints:

1. A § 5.1 Manifest endpoint in an agreed upon location that points to

2. An § 5.2 Accounts List endpoint

3. A § 5.3 Client Metadata endpoint

4. An § 5.4 ID Token endpoint

5. A § 5.5 Revocation endpoint

5.1. Manifest

The manifest discovery endpoint is an endpoint located at the IDP's fedcm.json file and serves as a discovery device to other endpoints provided by the IDP.

The manifest discovery endpoint is fetched:

(a) without cookies and (b) with a special § 5.6 Sec-FedCM-CSRF header.

For example:

GET /fedcm.json HTTP/1.1
Host: idp.example
Accept: application/json
Sec-FedCM-CSRF: random_value

The file is parsed expecting the following properties:

accounts_endpoint

A URL that points to an HTTP API that complies with the § 5.2 Accounts List API.

client_id_metadata_endpoint

A URL that points to an HTTP API that complies with the § 5.3 Client Metadata API.

id_token_endpoint

A URL that points to an HTTP API that complies with the § 5.4 ID Token API.

revocation_endpoint

A URL that points to an HTTP API that complies with the § 5.5 Revocation API.

For example:

{
  "accounts_endpoint": "/accounts.php",
  "client_id_metadata_endpoint": "/metadata.php",
  "id_token_endpoint": "/idtokens.php",
  "revocation_endpoint": "/revocation.php"
}

5.2. Accounts List

The accounts list endpoint provides the list of accounts the user has at the IDP.

The accounts list endpoint is fetched (a) with IDP cookies, (b) with a special § 5.6 Sec-FedCM-CSRF header and (c) without a Referer header.

For example:

GET /accounts_list.php HTTP/1.1
Host: idp.example
Accept: application/json
Cookie: 0x23223
Sec-FedCM-CSRF: random_value

The response is expected to have the following properties:

accounts (required)

A list of Account JSON.

branding (optional)

A set of Branding JSON options.

Every Account JSON is expected to have the following properties:

account_id (required)

An account identifier.

name (required)

The user’s full name.

given_name (required)

The user’s given name.

email (optional)

The user’s email address.

approved_clients (optional)

A list of RPs (in the form of Client IDs) this account is already registered with.

The Branding JSON is expected to have the following properties:

background_color (optional)

The background color of the button.

foreground_color (optional)

The foreground color of the button.

icons (optinal)

A list of Icon JSON objects.

The Icon JSON is expected to have the following properties:

url (required)

The url pointing to the icon image.

size (optional)

The size of the icon (assumed to be squared).

The color is a subset of CSS <color> syntax, namely <hex-color>s, hsl()s, rgb()s and <named-color>.

For example:

{
 "accounts": [{
   "account_id": "1234",
   "given_name": "John",
   "name": "John Doe",
   "email": "john_doe@idp.example",
   "picture": "https://idp.example/profile/123",
   "approved_clients": ["123", "456", "789"],
  }, {
   "account_id": "5678",
   "given_name": "Johnny",
   "name": "Johnny",
   "email": "johnny@idp.example",
   "picture": "https://idp.example/profile/456"
   "approved_clients": ["abc", "def", "ghi"],
  }],
  "branding": {
   "background_color": "green",
   "foreground_color": "0xFFEEAA",
   "icons": [{
     "url": "https://idp.example/icon.ico",
     "size": 10
   }],
 }
}

5.3. Client Metadata

The client metadata endpoint provides metadata about RPs.

The client medata endpoint is fetched (a) without cookies, (b) with a special § 5.6 Sec-FedCM-CSRF header and (c) with a Referer header indicating the RP's origin (as if Referer-Policy: strict-origin was in use).

The user agent also passes the client_id.

For example:

GET /client_medata.php?client_id=1234 HTTP/1.1
Host: idp.example
Referer: https://rp.example/
Accept: application/json
Sec-FedCM-CSRF: random_value

The file is parsed expecting the following properties:

privacy_policy_url

A link to the RP's privacy policy.

terms_of_service_url

A link to the RP's terms of service.

For example:

{
  "privacy_policy_url": "https://rp.example/clientmetadata/privacy_policy.html",
  "terms_of_service_url": "https://rp.example/clientmetadata/terms_of_service.html",
}

5.4. ID Token

The ID Token endpoint is responsible for minting a new id token for the user.

The ID Token endpoint is fetched (a) as a POST request, (b) with IDP cookies, (c) with a Referer header indicating the RP's origin (as if Referer-Policy: strict-origin was in use), and (d) with a special § 5.6 Sec-FedCM-CSRF header.

It will also contain the following parameters in the request body application/x-www-form-urlencoded:

client_id

The RP's client it

nonce

A random number of the choice of the RP

account_id

The account identifier that was selected.

consent_acquired

Whether the privacy policy and the terms of service were displayed to the user.

For example:

POST /fedcm_token_endpoint HTTP/1.1
Host: idp.example
Referer: https://rp.example/
Content-Type: application/x-www-form-urlencoded
Cookie: 0x23223
Sec-FedCM-CSRF: random_value
account_id=123&client_id=client1234&nonce=Ct60bD&consent_acquired=true

The response is parsed as a JSON file expecting the following properties:

id_token

The resulting id token.

For example:

{
  "id_token" : "eyJC...J9.eyJzdWTE2...MjM5MDIyfQ.SflV_adQssw....5c"
}

5.5. Revocation

The revocation endpoint is responsible for revoking all id tokens for the specified client ID for the user.

The request is made:

(a) as a POST request, (b) with IDP cookies, (c) with a special § 5.6 Sec-FedCM-CSRF header, and (d) with a Referer header indicating the RP's origin (as if Referer-Policy: strict-origin was in use).

It will also contain the following parameters in the request body application/x-www-form-urlencoded:

account_id

The account identifier for the user (e.g. email).

client_id

The RP's client id

For example:

POST /fedcm_revocation_endpoint HTTP/1.1
Host: idp.example
Referer: https://rp.example/
Content-Type: application/x-www-form-urlencoded
Cookie: 0x23223
Sec-FedCM-CSRF: random_value
account_id=123&client_id=client1234

If successful, the response is an empty response with an HTTP 204 code, otherwise an HTTP error code.

5.6. Sec-FedCM-CSRF

All FedCM HTTP requests sent by the browser must contain a header Sec-FedCM-CSRF with a random number as the value. This allows servers to verify that the request was initiated by the browser and not untrusted JavaScript.

6. The Relying Party API

RP's expose a § 6.1 Logout to facilitate with § 1.1.3.2 IDP Sign-out.

6.1. Logout

When IDPs call the § 7.4.2 IDP Sign-out API, every RP gets a chance to log the user out (e.g. clear cookies, clear local storage) via the logout endpoint.

The logout endpoint is an endpoint that is registered with the IDP out-of-band.

The logout endpoint is called (a) with a GET and (b) with the RP's cookies.

Note: the logout API introduces a credentialed request from the IDP to the RPs, so it exposes a potential tracking surface area. It is a fairly limited and controlled tracking area because the logout API is only available when accounts and sessions are already established between the IDP and the RP.

7. The Browser API

The Browser API exposes APIs to RPs and IDPs to call and intermediates the exchange of the user’s identity.

For RPs, it allows them to:

1. The § 7.2 The Sign-in API allows RP's users to § 1.1.1 Sign-up and § 1.1.1 Sign-up

2. The § 7.3 The Revocation API allows RP's users to go through § 1.1.4.1 RP Revocation of their accounts

3. The § 7.4.1 RP Sign-out API allows RPs to § 1.1.3.1 RP Sign-out of their accounts.

For IDPs, it allows them to:

1. The § 7.4.2 IDP Sign-out API allows IDPs to § 1.1.3.2 IDP Sign-out of their accounts.

The Browser API manages the lifecycle of the user’s accounts and sessions with an internal § 7.1 The State Machine.

7.1. The State Machine

Internally, the account management and session management APIs allows the user to explicitly move through the different stages of their accounts. At each stage, the state machine manages the RP's and the IDP's access to the appropriate browser capabilities.

Account State

Keeps track of whether the user has an account or not. Can be registered or (by default) unregistered.

Session State

Keeps track of whether the user has an open or closed session. Can be logged in or (by default) logged out.

7.2. The Sign-in API

7.2.1. RP Sign-in API

The Sign-up and Sign-in APIs used by the Relying Partys to ask the browser to intermediate the relationship with the Identity Provider and the provisioning of an id token.

The Relying Party makes no delineation between Sign-up and Sign-in, but rather calls the same API indistinguishably. The most important parameter to the API call is the set of Identity Providers that the Relying Party supports and has pre-registered with (i.e. it has a clientId).

Additionally, the Relying Party can control a variety of UX knobs. For example, whether to allow an § 1.1.2.1 Auto Sign-in flow and an AbortSignal in case it needs to abort the flow.

If all goes well, the Relying Party receives back an id token in the form of a signed JWT which it can use to authenticate the user.

async function login(signal) {
  const {idToken} = await navigator.credentials.get({
    // controls whether auto sign-in is enabled or not
    mediation: "optional",
    // controls abortions of the account chooser
    signal: signal

    // controls which identity providers to use
    federated: {
      // controls whether the account chooser is modal or not
      providers: [{
        url: "https://idp.example",
        // the pre-registered client id
        clientId: "123",
        nonce: "456"
      }],
    }
  });

  return idToken;
}

To accomplish that, this specification does three things:

1. It extends FederatedCredential with more fields.

2. It redefines FederatedCredential's [[DiscoverFromExternalSource]]().

3. It extends FederatedCredentialRequestOptions with more options.

First, this specification extends the FederatedCredential type adding two more fields:

enum FederatedCredentialApprovedBy {
  "auto",
  "user"
};

[Exposed=Window, SecureContext]
partial interface FederatedCredential {
  readonly attribute USVString idToken;
  readonly attribute FederatedCredentialApprovedBy approvedBy;
};

idToken

The id token.

approvedBy

When used in conjunction with mediation, it indicates whether the credential was provided via a § 1.1.2.1 Auto Sign-in or an § 1.1.2.2 Explicit Sign-in.

Second, it extends the FederatedCredentialRequestOptions by adding a list of FederatedIdentityProviders:

partial dictionary FederatedCredentialRequestOptions {
  sequence<(DOMString or FederatedIdentityProvider)> providers;
};

dictionary FederatedIdentityProvider {
  required USVString url;
  required USVString clientId;
  USVString nonce;
};

And finally, this specification overrides the FederatedCredential's [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) Method.

This algorithm runs in parallel inside the Credential Management § algorithm-request to request credentials and returns a set of FederatedCredential objects from a remote Identity Provider.

This internal method accepts three arguments:

origin

This argument is the relevant settings object's origin, as determined by the calling get() implementation, i.e., CredentialsContainer's Request a Credential abstract operation.

options

This argument is a CredentialRequestOptions object whose options.federated member contains a FederatedCredentialRequestOptions object specifying the exchange options.

sameOriginWithAncestors

This argument is a Boolean value which is true if and only if the caller’s environment settings object is same-origin with its ancestors. It is false if caller is cross-origin.

When this method is invoked, the user agent MUST execute the following algorithm:

1. If sameOriginWithAncestors is false, return a "NotAllowedError" DOMException.

   Note: This restriction aims to address the concern raised in Security Origin Confusion.

2. Assert: options["federated"]["providers"] exists.

3. Assert: options["federated"]["providers"] size is 1.

   Note: At some point we would like to support choosing accounts from multiple Identity Providers.

4. Let provider be options["federated"]["providers"][0].

5. Assert: provider["url"] exists.

6. Assert: provider["clientId"] exists.

7. Assert: provider["nonce"] exists.

8. Let manifest be the result of running the fetch the manifest algorithm with the provider.

9. Let accounts list be the result of running the fetch the accounts list algorithm.

10. Let account be the result of running the select an account from the accounts list algorithm.

11. If the Account State is unregistered

    1. Return the result of running the sign-up algorithm.

12. If the Session State is logged out then

    1. Return the result of running the explicit sign-in algorithm.

13. Return the result of running the auto sign-in algorithm.

To sign-up the user run this algorithm:

1. Gather explicit intent to create an account

2. Gather explicit agreement with the Privacy Policy

3. Gather explicit agreement with the Terms of Service

4. Set the account’s Account State from unregistered to registered.

5. Set the account’s Session State from logged out to logged in.

6. Return the result of minting a new id token.

To select an account from the accounts list run this algorithm:

1. If accounts list’s size is 1

   1. Let account be accounts list[0]

   2. Return account

2. Display an account chooser

3. Let account be an account that the user manually selects from the accounts chooser

4. Return account

To sign-in the user run this algorithm:

1. Assert that the Account State is registered

2. Set the account’s Session State from logged out to logged in.

3. Return the result of minting a new id token.

To auto sign-in the user run this algorithm:

1. Return the result of running the sign-in algorithm.

To explicit sign-in the user run this algorithm:

1. Gather explicit confirmation that the user wants to sign-in to Relying Party with their Identity Provider's account

2. Return the result of running the sign-in algorithm.

To fetch the manifest configuration file, run this algorithm:

1. Let the manifest url be the relative url "fedcm.json" of provider["url"]

2. Return the result of fetching the manifest url with the Sec-FedCM-CSRF header but without the Identity Provider's cookies.

To fetch the accounts list run this algorithm:

1. Let the accounts_endpoint url be the relative url manifest["accounts_endpoint"] of provider["url"]

2. Let the accounts list be the result of fetching the accounts_endpoint with the Identity Provider's cookies.

3. Return the accounts list

To fetch the client id metadata run this algorithm:

1. Let the client_id_metadata_endpoint url be the relative url manifest["client_id_metadata_endpoint"] of provider["url"]

2. Let the policies be the result of fetching the client_id_metadata_endpoint with the Sec-FedCM-CSRF header but without the Identity Provider's cookies.

3. Return policies

The Privacy Policy are the policies described at privacy_policy_url.

The Terms of Service are the policies described at terms_of_service_url.

To mint a new id token, run the following algorithm:

1. Let token be the result of making a POST request to the manifest["id_token_endpoint"] with:

   • Let the account_id be account["account_id"].

   • Let the request be a new object with

     • Let client_id be provider["clientId"].

     • Let the nonce be provider["nonce"].

2. Return a new FederatedCredential as:

   • id with account["account_id"]

   • idToken with token

   • provider with provider["url"]

7.2.2. IDP Sign-in API

The IDP Sign-in API allows an IDP to sign the user into a RP by storing a FederatedCredential that can later be retrieved by a RP.

Its effect is equivalent to the § 7.2.1 RP Sign-in API in its effect, except that it is designed to be called while the user is at the IDP rather than at the RP.

async function login({id, name, iconURL}) {
  const credential = new FederatedCredential({
    id: id,
    provider: 'https://idp.example',
    name: name,
    iconURL: iconUrl,
    client_id: "1234",
  });

  return await navigator.credentials.store(credential);
}

7.3. The Revocation API

Whenever the user decides to delete their account on the Relying Party the Relying Party can call an API to let the Identity Provider and the browser know.

Upon return to the Relying Party, the user goes through a § 1.1.1 Sign-up flow instead of a § 1.1.2 Sign-in flow.

async function revoke(accountId, identityProvider) {
  return await FederatedCredential.revoke(accountId, identityProvider);
}

This specification extends the FederatedCredential interface with an extra static method:

[Exposed=Window, SecureContext]
partial interface FederatedCredential {
  static Promise<undefined> revoke(USVString accountId, FederatedIdentityProvider provider);
};

Note: go over the revocation API.

7.4. The Sign-out API

7.4.1. RP Sign-out

When a user wants to log out of their session in the Relying Party, the Relying Party can let the browser know that it wants the § 1.1.2.1 Auto Sign-in flow to be disabled, so that the user doesn’t get into an infinite loop.

It does so by calling the preventSilentAccess() API, which clear the user’s current account session and takes them to an § 1.1.2.2 Explicit Sign-in flow whenever the user wants to log back in.

function logout() {
  navigator.credentials.preventSilentAccess();
}

Note: go over the RP sign-out API.

7.4.2. IDP Sign-out

In enterprise scenarios, it is common for the user to want to clear all of their existing sessions in all of the Relying Partys they are logged into.

It does so by being navigated to their Identity Provider who initiates what’s called a Front-Channel Logout.

The browser exposes an API that takes the list of Relying Partys that the Identity Provider wants to initiate the logout which are loaded in parallel with cookies.

Each Relying Party endpoint is responsible for clearing its local state (e.g. clearing cookies).

After the completion of this API, the user’s session is cleared and will go through an § 1.1.2.2 Explicit Sign-in upon return.

async function logout() {
  await FederatedCredential.logoutRPs([{
      url: "https://rp1.example",
      accountId: "123",
    }, {
      url: "https://rpN.example",
      accountId: "456",
    }]);
}

IDPs can call FederatedCredential.logoutRPs(...) to log the user out of the RPs they are signed into.

dictionary FederatedCredentialLogoutRequest {
    required USVString url;
    required USVString accountId;
};

[Exposed=Window, SecureContext]
partial interface FederatedCredential {
  static Promise<undefined> logoutRPs(optional sequence<FederatedCredentialLogoutRequest> logout_requests = []);
};

Note: go over how this is implemented.

7.5. Backwards Compatibility

Note: go over how we are planning to deal with backwards compatibility.

8. Security

Note: go over security.

9. Privacy

9.1. Privacy Threat Model

This section is intended to provide a comprehensive overview of the privacy risks associated with federated identity on the web for the purpose of measuring the privacy risks and benefits of proposed browser intermediation designs.

See also:

• Web Platform Design Principles

• W3C TAG Ethical Web Principles

• Self-Review Questionnaire: Security and Privacy § threats

• Privacy Considerations for Web Protocols § privacy-threats

• Privacy Considerations for Internet Protocols § section-5

• Privacy Model

• Editor’s Draft for a Web Privacy Threat Model

• Security and Privacy Considerations for SAML V2.0

9.1.1. Principals

This section describes the three principals that would participate in an invocation of the API and expectations around their behavior.

1. The User Agent implements § 7 The Browser API and controls the execution contexts for the RP and IDP content. The user agent is assumed to be trusted by the user, and transitively trusted by the RP and IDP.

2. Relying Partys (RPs) are first party websites that invoke the FedCM API for the purpose of authenticating a user to their account or for requesting information about that user. A well-behaving RP would only invoke the API following a clear user signal -- typically, clicking a sign-in button. Since any site can invoke the API, RPs cannot necessarily be trusted to limit the user information it collects or use that information in an acceptable way.

3. Identity Providers (IDPs) are third party websites that are the target of a FedCM call to attempt to fetch an ID token. Usually the IDP has a higher level of trust than the RP since it already has the user’s personal information, but it is possible that the IDP might use the user’s information in non-approved ways. It is possible that the IDP specified in the API call may not be an IDP the user knows about, or may not be a bona fide IDP at all, in which case it likely does not have personal user information in advance, but also might be less accountable for its behavior.

9.1.2. High-level threats

Privacy Considerations for Internet Protocols describes the following high-level privacy threats, which the TAG has adopted into Self-Review Questionnaire: Security and Privacy § threats:

Surveillance

Surveillance is the observation or monitoring of an individual’s communications or activities.

Stored Data Compromise

End systems that do not take adequate measures to secure stored data from unauthorized or inappropriate access.

Intrusion

Intrusion consists of invasive acts that disturb or interrupt one’s life or activities.

Misattribution

Misattribution occurs when data or communications related to one individual are attributed to another.

Correlation

Correlation is the combination of various pieces of information related to an individual or that obtain that characteristic when combined.

Identification

Identification is the linking of information to a particular individual to infer an individual’s identity or to allow the inference of an individual’s identity.

Secondary Use

Secondary use is the use of collected information about an individual without the individual’s consent for a purpose different from that for which the information was collected.

Disclosure

Disclosure is the revelation of information about an individual that affects the way others judge the individual.

Exclusion

Exclusion is the failure to allow individuals to know about the data that others have about them and to participate in its handling and use.

These threats combine into the particular concrete threats we want web specifications to defend against, described in subsections here:

9.1.3. Attack Scenarios

This section describes the scenarios in which various agents might attempt to gain user information. It considers the possibilities when:

• The RP is collecting information,

• The IDP is collecting information, or

• Both the RP and the IDP are colluding.

For the purposes of this section, a principal is considered to be participating in the collection of information if it directly or indirectly performs actions with the aim of realizing one of the above threats.

Note: An example of indirect collusion would be an RP importing a script supplied by an IDP where the IDP intends to track users.

For the purpose of discussion this document assumes that third-party cookies are disabled by default and are no longer effective for use in tracking mechanisms, and also some form of mitigations are implemented against ‘bounce tracking’ using link decoration or postMessage. Most of these scenarios consider how user tracking might happen without them.

See also:

1. Pervasive Monitoring Is an Attack

9.1.3.1. By the RP

9.1.3.1.1. Cross-Site Correlation

Related to:

• Target Privacy Threat Model § hl-recognition-cross-site

• Privacy Considerations for Web Protocols: Correlation

• RFC6973: Correlation

Correlation is the combination of various pieces of information related to an individual or that obtain that characteristic when combined.

This attack happens when multiple RPs collude to use their user’s data to correlate them and build a richer profile.

When a user willingly provides their full name, email address, phone number, etc, to multiple relying parties, those relying parties can collaborate to build a profile of that user and their activity across collaborating sites.

Sometimes this is referred to as joining since it amounts to a join of user records between the account databases of multiple RPs.

This correlation and profile-building is outside the user’s control and entirely out of the User Agent’s or IDP’s view.

A generalization of § 9.1.3.1.1 Cross-Site Correlation is:

(RP Secondary Use) Relying Party uses user information for purposes not authorized by the user:

When the user agrees to allow the IDP to provide information to the RP, the consent is specific to certain purposes, such as sign-in and personalization. The RP might use that data for other purposes that the user would not expect and did not authorize, such as selling email addresses to a spam list.

Spamming risk can exist even when using directed identifiers.

9.1.3.1.2. Same-Site Identification

Identification is the linking of information to a particular individual to infer an individual’s identity or to allow the inference of an individual’s identity.

This attack happens when the Relying Party employs client state-based tracking to identify user.

Any API that exposes any kind of client state to the web risk becoming a vector for fingerprinting or ‘supercookies’.

This risk would be increased by any proposal for browser mediation that adds directly (or indirectly) detectable client state.

See also:

1. Mitigating Browser Fingerprinting in Web Specifications

9.1.3.1.3. Data Compromise

This attack scenario happens when the RP takes advantage of inadequate measures (by the IDP or the UA) to secure stored data to obtain personal user information without their consent.

This can happen if user consent mechanisms are missing, inadequate, or susceptible to bypass.

See also:

1. Target Privacy Threat Model § stored-data-compromise

2. Privacy Considerations for Internet Protocols § section-5.1.2

9.1.3.2. By the IDP

9.1.3.2.1. Secondary Use

Related to:

• Self-Review Questionnaire: Security and Privacy § third-party-tracking

Secondary use is the use of collected information about an individual without the individual’s consent for a purpose different from that for which the information was collected.

This attack happens when Identity Providers misuses the the information collected to enable sign-in for other purposes.

Existing federation protocols require that the IDP know which service is requesting an ID token in order to allow identity federation (e.g. the IDP must know the OAuth client_id).

Identity providers can use this fact to build profiles of users across sites where the user has decided to use federation with the same account. This profile could be used, for example, to serve targeted advertisements to those users browsing on sites that the IDP controls.

This risk can exist even in the case where the IDP does not having pre-existing user account information (for instance, if it is not a _bona fide_ IDP), because FedCM requests sent to the IDP are credentialed. This is more likely to occur if the RP is colluding with the IDP to enable tracking; expanded variants are described in § 9.1.3.3.3 Timing Attacks.

9.1.3.2.2. Impersonation

Since IDPs have unconstrained ability to issue ID tokens, they are capable of logging in to users’ federated accounts without user knowledge or action, impersonating the user and potentially gaining full access to the user’s account on the RP.

9.1.3.3. By Collusion

9.1.3.3.1. Intrusion

From Target Privacy Threat Model § hl-intrusion

Privacy harms don’t always come from a site learning things.

From RFC6973: Intrusion

Intrusion consists of invasive acts that disturb or interrupt one’s life or activities. Intrusion can thwart individuals' desires to be left alone, sap their time or attention, or interrupt their activities.

In the context of federation, intrusion happens when an RP and an IDP are colluding to invasively and aggressively recommend the user to login disproportionally to the their intent.

Much like unsolicited notifications, an RP can collude with an IDP to aggressively log users in.

See also:

1. Web Platform Design Principles § safe-to-browse

9.1.3.3.2. Back channel

This attack scenario happens when IDP exceed the user’s information sharing permission.

Existing federated identity protocols are clear on what information an RP is requesting, which the IDP can provide. While the browser can inspect the request and response and consider whether user permission has been granted for that transfer, it is difficult to know that there is no additional information embedded in the response. An example could be if the IDP encodes an identifier that could be used to load user-targeted advertisements on RP pages, which could be of value where the IDP has much more profiling information about the user.

Another example is if identifying information is shared out-of-band, invisible to the browser, in which case it could contain anything.

9.1.3.3.3. Timing Attacks

The potential for IDPs profiling users based on their visits to RPs § 9.1.3.2.1 Secondary Use can be partially mitigated by hiding the RP from the IDP until after the user has consented to that tracking risk.

However, there is residual risk in cases where the RP and IDP are colluding.

If a credentialed request is sent to the IDP that does not explicitly identify the RP, either of the following would still allow tracking by the IDP (again, possibly not a _bona fide_ IDP that has existing knowledge of the user):

• The RP controlling any field in the request that can be used to convey identifying data in the request that the IDP could correlate to other requests from other RPs;

• The RP being able to provide fine-resolution timing information about the request to the IDP out of band.

The timing information can enable tracking in the following way:

1. The RP logs the time at which it invoked the API, and

2. The IDP logs the time at which it received a credentialed FedCM request from the user, and later

3. They attempt to link the invocation and the request together using that information.

Notably, this is possible without FedCM using simple cross-origin top-level navigations, but using FedCM for this purpose would worsen the problem if it improved timing resolution or was less visible to users.

See also:

1. Web Platform Design Principles § safe-to-browse

9.2. Mitigation Strategies

In this section we’ll go over some strategies used in this specification to mitigate the privacy threats.

9.2.1. Minimal Disclosure

There is a series of privacy threats that can be mitigated by disclosing the least amount of identifying information and limiting its use as much as possible. Two notable strategies are described in the sections below.

9.2.1.1. Directed Identifiers

Mitigates:

• § 9.1.3.1.1 Cross-Site Correlation

Note: directed, sharding, partitioning

The problem of RPs joining user data via back-channels is inherent to the proliferation of identifying user data. This can be solved by issuing directed identifiers that provide an effective handle to a user’s identity with a given IDP that is unique and therefore cannot be correlated with other RPs.

In the past, there have been schemes to accomplish this using one-way hashes of, for example, the user’s name, the IDP and the RP.

Note: this mitigation is not robust against § 9.1.3.3.2 Back channel, or the § 9.1.3.2.1 Secondary Use. Also, collaborating RPs might be able to defeat this mitigation by sharing the same CLIENT_ID, although possibly this could be detected and presumably would violate RP agreements with IDPs with § 9.2.5 Pre-registration.

9.2.1.2. Self Presentation

Mitigates:

• § 9.1.3.2.1 Secondary Use and

• § 9.1.3.3.3 Timing Attacks

Note: unbundling issuing from presentation

Preventing tracking of users by the IDP is difficult because the RP has to be coded into the identity token for security reasons, to prevent reuse of the token. There have been cryptographic schemes developed to blind the IDP to the RP while still preventing token reuse in that way (see Mozilla’s personas) but there are other valid uses that the IDP has for knowing the RP, such as fraud and abuse prevention.

9.2.2. Mediation

Mitigates:

• § 9.1.3.1.1 Cross-Site Correlation,

• § 9.1.3.1.3 Data Compromise,

• § 9.1.3.3.3 Timing Attacks

• § 9.1.3.3.1 Intrusion

IDPs, whom the user has entrusted with their personal data, are currently responsible for ensuring that the user consents to their information being shared. With browser mediation in place, the user agent might have to assume responsibility for ensuring the user understands what is being shared and that it is intentional. This is certainly the case if the browser is able to entirely intermediate the identity flow without showing any IDP web content, but also might be desirable if there are concerns that the IDP is not collecting consent in an adequate manner.

Additionally, a consent prompt preceding the sharing of the RP’s request to the IDP can mitigate risks around IDP tracking of user visits to RPs.

See also:

1. Web Platform Design Principles § consent

2. Self-Review Questionnaire: Security and Privacy § user-mediation

3. Privacy Considerations for Internet Protocols § page-23

4. Ethical Principles: The web must make it possible for people to verify the information they see

5. Ethical Principles: The web must enhance individuals' control and power

6. The Rule of Least Power

9.2.2.1. Verification

Mitigates:

• § 9.1.3.1.1 Cross-Site Correlation,

The User Agent can mitigate § 9.1.3.1.1 Cross-Site Correlation by inspecting the contents of the data exchange, and providing the necessary user controls.

For example, it can inspect the email address that is being exchanged and verify whether it is a directed identifier or not (and warn the user proportionally).

9.2.2.2. Activation

The User Agent can mitigate § 9.1.3.3.1 Intrusion by mediating the user controls and offering them proportionally to the intent of the user or the privacy risks involved.

For example, a User Agent can choose to show a loud / disruptive modal mediated dialog when it has enough confidence of the user’s intent or show a quiet / conservative UI hint when it doesn’t.

A User Agent could also choose to control disruption of the user’s experience based on the risks involved.

For example, when a directed identifier is being exchanged it can be more confident of the unintended consequeces and offer a more aggressive user experience, whereas when global identifiers are exchanged a more conservative user experience.

See also:

• Requiring user gesture to call WebAuthn API

• Require user gesture to request notification permissions

• WHATWG User Activation

• Querying User Activation

9.2.3. Policy

Mitigates:

• § 9.1.3.2.2 Impersonation,

• § 9.1.3.3.2 Back channel

Beyond technical constraints, the browser can recognize explicit assertions by the IDP about the privacy characteristics it provides and rely on those assertions in order to guide the user appropriately. An example is a hypothetical case in which the IDP asserts it will only issue directed identifiers and will not provide identifying information to the RPs out of view of the browser. In that case the browser may not have to warn the user about sharing personalized information.

9.2.4. Denylists

Mitigates:

• Potentially all threats, but is subject to the likelihood of bad behavior being detected, which for some might be difficult.

Any RPs or IDPs observed to be using this API to compromise user privacy in a deceptive or abusive manner could be explicitly blocked from using it, or potentially added to the SafeBrowsing blocklist so that they cannot be loaded at all.

9.2.5. Pre-registration

Mitigates:

• § 9.1.3.1.3 Data Compromise,

• § 9.1.3.1.1 Cross-Site Correlation

Currently, IDPs require that an RP pre-registers and agrees to specific terms before the IDP will issue an ID token to them. This conflicts with the previous mitigation, but can provide a measure of RP accountability.

9.2.6. 2FA

Mitigates:

• § 9.1.3.2.2 Impersonation,

10. Extensibility

Note: go over the extensibility mechanisms.

11. Acknowledgements

Note: write down the Acknowledgements section.